Method for Automated Harvesting of Data from A Web site using a Voice Portal System

ABSTRACT

A system is provided for developing and deploying a voice application using Web-based data as source data over a communications network to one or more recipients. The system has a voice application server capable of accessing a network server and Website hosted therein, a network communications server for routing the voice applications to their intended recipients, and a computer station running voice application software having control access to at least the voice application server, the computer station capable of accessing the network server and Website. An operator of the computer station creates and provides templates for the voice application server to use in data-to-voice rendering.

CROSS-REFERENCE TO RELATED DOCUMENTS

The present application is a Continuation of co-pending U.S. patentapplication Ser. No. 10/190,077, filed on Jul. 2, 2002, the disclosureof which is incorporated by reference herein. That application is aContinuation In Part of a U.S. patent application, Attorney docket No.P8100 entitled “Method and Apparatus for Development and Deployment of aVoice Software Application for Distribution to one or more ApplicationConsumers”, filed on Jun. 14, 2002, the disclosure of which isincorporated by reference herein in its entirety. That parent case filedon Jun. 14, 2002 claimed priority to provisional application Ser. No.60/302,736 filed on Jul. 3, 2001, and incorporates all disclosure ofthat provisional application by reference. The present applicationtherefore claims priority to both of the applications described above inthis paragraph.

FIELD OF THE INVENTION

The present invention is in the area of software application developmentand pertains particularly to methods and apparatus for auto harvestingtemplate-based web content using a VXML-enabled voice portal system.

BACKGROUND

A speech application is one of the most challenging applications todevelop, deploy and maintain in a communications (typically telephony)environment. Expertise required for developing and deploying a viableapplication includes expertise in computer telephony integration (CTI)hardware and software, voice recognition software, text-to-speechsoftware, and speech application logic.

With the relatively recent advent of voice extensive markup language(VXML) the expertise require to develop a speech solution has beenreduced somewhat. VXML is a language that enables a software developerto focus on the application logic of the voice application without beingrequired to configuring underlying telephony components. Typically, thedeveloped voice application is run on a VXML interpreter that resides onand executes on the associated telephony system to deliver the solution.

As is shown in FIG. 1A (prior art) a typical architecture of aVXML-compliant telephony system comprises a voice application server(110) and a VXML-compliant telephony server (130). Typical steps fordevelopment and deployment of a VXML enabled IVR solutions are brieflydescribed below using the elements of FIG. 1A.

Firstly, a new application database (113) is created or an existing oneis modified to support VXML. Application logic 112 is designed in termsof workflow and adapted to handle the routing operations of the IVRsystem. VXML pages, which are results of functioning application logic,are rendered by a VXML rendering engine (111) based on a specifiedgeneration sequence.

Secondly, an object facade to server 130 is created comprising thecorresponding VXML pages and is sent to server 130 over a network (120),which can be the Internet, an Intranet, or an Ethernet network. The VXMLpages are integrated into rendering engine 111 such that they can bedisplayed according to set workflow at server 110.

Thirdly, the VXML-telephony server 130 is configured to enable properretrieval of specific VXML pages from rendering engine 111 within server110. A triggering mechanism is provided to server 110 so that when atriggering event occurs, an appropriate outbound call is placed fromserver 110.

A VXML interpreter (131), a voice recognition text-to-speech engine(132), and the telephony hardware/software (133) are provided withinserver 130 and comprise server function. In prior art, the telephonyhardware/software 130 along with the VXML interpreter 131 are packagedas an off-the-shelf IVR-enabling technology. Arguably the most importantfeature, however, of the entire system is the application server 110.The application logic (112) is typically written in a programminglanguage such as Java and packaged as an enterprise Java Bean archivesThe presentation logic required is handled by rendering engine 111 andis written in JSP or PERL.

An enhanced voice application system is known to the inventor anddisclosed in the U.S. patent application entitled “Method and Apparatusfor Development and Deployment of a Voice Software Application forDistribution to one or more Application Consumers” to which thisapplication claims priority. That system uses a voice application serverthat is connected to a data network for storing and serving voiceapplications. The voice application server has a data connection to anetwork communications server connected to a communications network suchas the well-known PSTN network. The communication server routes thecreated voice applications to their intended recipients.

A computer station is provided as part of the system and is connected tothe data network and has access to the voice application server. Aclient software application is hosted on the computer station for thepurpose of enabling users to create applications and manage theirstates. In this system, the user operates the client software hosted onthe computer station in order to create voice applications throughobject modeling and linking. The applications, once created, are thenstored in the application server for deployment. The user can controland manage deployment and state of deployed applications includingscheduled deployment and repeat deployments in terms of intendedrecipients.

The system described above is quite advantageous in that a developerusing the system need not be highly skilled in VXML languagecompilation, database programming, or advanced server design. Moreover,the system substantially reduces the amount of time allotted to projectdevelopment. Still further, the system supports changes or modificationsperformed by anyone other than the developer without having to depend onthe original author (because of his or her experience) to debug or makechanges.

With the advent of the well known Internet network and growingtechnology to bridge two disparate networks such as the Internet and aPSTN network, the present inventors have concluded that Web data fromWeb sites should be a target data set for harvesting and conversion intoa voice application that could then be routed to one or more users.

What is therefore clearly needed is a VMXL interface to a Web serverthat is capable of harvesting data from individual Web sites hosted onthe server.

SUMMARY

In a preferred embodiment of the present invention a system fordeveloping and deploying a voice application using Web-based data assource data over a communications network to one or more recipients isprovided, comprising a voice application server connected to a datanetwork for storing and serving voice applications, the voiceapplication server capable of accessing a network server and Websitehosted therein, a network communications server connected to the datanetwork and to the communications network for routing the voiceapplications to their intended recipients, a computer station connectedto the data network having control access to at least the voiceapplication server, the computer station capable of accessing thenetwork server and Website hosted therein, and a software applicationrunning on the computer station for creating applications and managingtheir states. The system is characterized in that a developer operatingthe software application from the computer station accesses the targetserver and Website and creates at least one template for holding Webdata according to logical order of site construction and links thetemplates to voice applications created by object modeling and linking,whereupon according to a triggering event, the triggered voiceapplication accesses the intended Website and retrieves refreshed datafrom the site into the template and renders the retrieved data as voicedelivered to intended recipients.

In a preferred embodiment the data network is the Internet network. Alsoin a preferred embodiment the voice application is delivered over apublic-switched-telephony-network to a voice portal accessed by theintended recipients.

In some embodiments the security protocol used by the accessed Websiteis transferred as a voice access mechanism to the intended recipients.Also in some embodiments the data network connections of the computerstation and of the voice application server are separate data networkconnections. In some cases the voice applications are scheduled fordelivery at a specific time delivery made by outbound dialing andconnection to a telephone of the intended recipient. The voiceapplications may be accessed by the intended recipients in real time.

In another aspect of the invention a voice application server forrendering voice dialog using Web-based data as source data is provided,comprising an instance of voice application development software, adatabase resource adapter, an instance of application logic;

a data rendering engine, and a network access line and softwareapplication for accessing servers and Websites hosted therein for thepurpose of harvesting data there from for use in voice applicationcreation and deployment. The server is characterized in that accordingto a trigger, the voice application server navigates to one or moreservers and one or more Websites and obtains refreshed data there fromconverting the data to voice dialog and delivering the dialog to a voiceportal accessible to an intended recipient.

In many preferred embodiments the network is the Internet network. Alsoin some preferred embodiments the voice application is delivered over apublic-switched-telephony-network to a voice portal accessed by theintended recipients. In some cases the security protocol used by theaccessed Website is transferred as a voice access mechanism to theintended recipients. Also in some cases the voice applications arescheduled for delivery at a specific time delivery made by outbounddialing and connection to a telephone of the intended recipient. Theapplications may be accessed by the intended recipients in real time.

In some embodiments of the invention a template is created for storingfield and source data from a Website and the template is used in voicerendering in the server. The software for network access may be abrowser application.

Embodiments of the invention taught in enabling detail below provide newand enhanced functionality for rendering information into audio form.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating a basic architecture of aVXML-enabled IVR development and deployment environment according toprior-art.

FIG. 1B is a block diagram illustrating the basic architecture of FIG.1A enhanced to practice the present invention.

FIG. 2 is a process flow diagram illustrating steps for creating a voiceapplication shell or container for a VXML voice application according toan embodiment of the present invention.

FIG. 3 is a block diagram illustrating a simple voice applicationcontainer according to an embodiment of the present invention.

FIG. 4 is a block diagram illustrating a dialog object model accordingto an embodiment of the present invention.

FIG. 5 is a process flow diagram illustrating steps for voice dialogcreation for a VXML-enabled voice application according to an embodimentof the present invention.

FIG. 6 is a block diagram illustrating a dialog transition flow afterinitial connection with a consumer according to an embodiment of thepresent invention.

FIG. 7 is a plan view of a developer's frame containing a developer'slogin screen of according to an embodiment of the present invention.

FIG. 8 is a plan view of a developer's frame containing a screen shot ofa home page of the developer's platform interface of FIG. 7.

FIG. 9 is a plan view of a developer's frame containing a screen shot ofan address book 911 accessible through interaction with the optionAddress in section 803 of the previous frame of FIG. 8.

FIG. 10 is a plan view of a developer's frame displaying a screen 1001for creating a new voice application.

FIG. 11 is a plan view of a developer's frame illustrating screen ofFIG. 10 showing further options as a result of scrolling down.

FIG. 12 is a screen shot of a dialog configuration window illustrating adialog configuration page according to an embodiment of the invention.

FIG. 13 is a screen shot 1300 of dialog design panel of FIG. 12illustrating progression of dialog state to a subsequent contact.

FIG. 14 is a screen shot of a thesaurus configuration window activatedfrom the example of FIG. 13 according to a preferred embodiment.

FIG. 15 is a plan view of a developer's frame illustrating a screen formanaging created modules according to an embodiment of the presentinvention.

FIG. 16 is a block diagram of the dialog transition flow of FIG. 6enhanced for Web harvesting according to an embodiment of the presentinvention.

FIG. 17 is a block diagram of the voice application distributionenvironment of FIG. 1B illustrating added components for automated Webharvesting and data rendering according to an embodiment of the presentinvention.

DETAILED DESCRIPTION

According to preferred embodiments of the present invention, theinventor teaches herein, in an enabling fashion, a novel system fordeveloping and deploying real-time dynamic or static voice applicationsin an object-oriented way that enables inbound or outbound delivery ofIVR and other interactive voice solutions in supported communicationsenvironments.

FIG. 1A is a block diagram illustrating a basic architecture of aVXML-enabled IVR development and deployment environment according toprior art. As described with reference to the background section, theprior-art architecture of this example is known to and available to theinventor. Developing and deploying voice applications for theillustrated environment, which in this case is a telephony environment,requires a very high level of skill in the art. Elements of thisprior-art example that have already been introduced with respect to thebackground section of this specification shall not be re-introduced.

In this simplified scenario, voice application server 110 utilizesdatabase/resource adapter 113 for accessing a database or otherresources for content. Application logic 112 comprising VXML script,business rules, and underlying telephony logic must be carefullydeveloped and tested before single applications can be rendered byrendering engine 111. Once voice applications are complete and servablefrom server 110, they can be deployed through data network 120 totelephony server 130 where interpreter 131 and text-to speech engine 132are utilized to formulate and deliver the voice application in useableor playable format for telephony software and hardware 133. Theapplications are accessible to a receiving device, illustrated herein asdevice 135, a telephone, through the prevailing network 134, which is inthis case a public-switched-telephone-network (PSTN) linking thetelephony server to the consumer (device 135) generally through atelephony switch (not shown).

Improvements to this prior-art example in embodiments of the presentinvention concern and are focused in the capabilities of applicationserver 110 with respect to development and deployment issues and withrespect to overall enhancement to response capabilities and options ininteraction dialog that is bi-directional. Using the description ofexisting architecture deemed state-of-art architecture, the inventorherein describes additional components that are not shown in theprior-art example of FIG. 1A, but are illustrated in a novel version ofthe example represented herein by FIG. 1B.

FIG. 1B is a block diagram illustrating the basic architecture of FIG.1A enhanced to illustrate an embodiment of the present invention.Elements of the prior-art example of FIG. 1A that are also illustratedin FIG. 1B retain their original element numbers and are notre-introduced. For reference purposes an entity (a person) that developsa voice application shall be referred to hereinafter in thisspecification as either a producer or developer.

A developer or producer of a voice application according to anembodiment of the present invention operates preferably from a remotecomputerized workstation illustrated herein as station 140. Station 140is essentially a network-connected computer station. Station 140 may behoused within the physical domain also housing application server 110.In another embodiment, station 140 and application server 110 may residein the same machine. In yet another embodiment, a developer may operatestation 140 from his or her home office or from any network-accessiblelocation including any wireless location.

Station 140 is equipped with a client software tool (CL) 141, which isadapted to enable the developer to create and deploy voice applicationsacross the prevailing system represented by servers 110, 130, and byreceiving device 135. CL 141 is a Web interface application similar toor incorporated with a Web browser application in this example, howeverother network situations may apply instead. CL 141 contains the softwaretools required for the developer to enable enhancements according toembodiments of the invention. Station 140 is connected to a voice portal143 that is maintained either on the data network (Internet, Ethernet,Intranet, etc.) and/or within telephony network 134. In this exampleportal 143 is illustrated logically in both networks. Voice portal 143is adapted to enable a developer or a voice application consumer to callin and perform functional operations (such as access, monitor, modify)on selected voice applications.

Within application server 110 there is an instance of voice applicationdevelopment server 142 adapted in conjunction with the existingcomponents 111-113 to provide dynamic voice application development anddeployment according to embodiments of the invention.

Portal 143 is accessible via network connection to station 140 and via anetwork bridge to a voice application consumer through telephony network134. In one example, portal 143 is maintained as part of applicationserver 110. Portal 143 is, in addition to an access point for consumersis chiefly adapted as a developer's interface server. Portal 143 isenabled by a SW instance 144 adapted as a server instance to CL 141. Ina telephony embodiment, portal 143 may be an interactive voice response(IVR) unit.

In a preferred embodiment, the producer or developer of a voiceapplication accesses application server 110 through portal 143 and datanetwork 120 using remote station 140 as a “Web interface” and firstcreates a list of contacts. In an alternative embodiment, station 140has direct access to application server 110 through a network interface.Contacts are analogous to consumers of created voice applications. CL141 displays, upon request and in order of need, all of the requiredinteractive interfaces for designing, modifying, instantiating, andexecuting completed voice applications to launch from application server110 and to be delivered by server 130.

The software of the present invention enables voice applications to bemodeled as a set of dialog objects having business and telephony (orother communication delivery/access system) rules as parameters withoutrequiring the developer to perform complicated coding operations. Adialog template is provided for modeling dialog states. The dialogtemplate creates the actual speech dialog, specifies the voiceapplication consumer (recipient) of the dialog, captures the responsefrom the voice application consumer and performs any follow-up actionsbased upon system interpretation of the consumer response. A dialog is areusable component and can be linked to a new dialog or to an existing(stored) dialog. A voice application is a set of dialogs inter-linked bya set of business rules defined by the voice application producer. Oncethe voice application is completed, it is deployed by server 110 and iseventually accessible to the authorized party (device 135) throughtelephony server 130.

The voice applications are in a preferred embodiment in the form of VXMLto run on VXML-compliant telephony server 130. This process is enabledthrough VXML rendering engine 111. Engine 111 interacts directly withserver 130, locates the voice application at issue, retrieves its voiceapplication logic, and dynamically creates the presentation in VXML andforwards it to server 130 for processing and delivery. Once interpreter131 interprets the VXML presentation it is sent to or accessible todevice 135 in the form of an interactive dialog (in this case an IVRdialog). Any response from device 135 follows the same path back toapplication server 110 for interpretation by engine 111. Server 110 thenretrieves the voice application profile from the database accessiblethrough adapter 113 and determines the next business rule to executelocally. Based upon the determination a corresponding operationassociated with the rule is taken. A next (if required) VXMLpresentation is then forwarded to rendering engine 111, which in turndynamically generates the next VXML page for interpretation, processingand deployment at server 130. This two-way interaction between theVXML-compliant telephony server (130) and the voice application server(110) continues in the form of an automated logical sequence of VXMLdialogs until the voice application finally reaches its terminationstate.

A voice application (set of one or more dialogs) can be delivered to theconsumer (target audience) in outbound or inbound fashion. For aninbound voice application, a voice application consumer calls in tovoice portal 143 to access the inbound voice application served fromserver 130. The voice portal can be mapped to a phone number directly oras an extension to a central phone number. In a preferred embodiment thevoice portal also serves as a community forum where voice applicationproducers can put their voice applications into groups for easy accessand perform operational activities such as voice application linking,reporting, and text-to-speech recording and so on.

For an outbound voice application there are two sub-types. These areon-demand outbound applications and scheduled outbound applications. Foron-demand outbound applications server 110 generates an outbound call assoon as the voice application producer issues an outbound commandassociated with the application. The outbound call is made to the targetaudience and upon the receipt of the call the voice application islaunched from server 130. For scheduled outbound applications, theschedule server (not shown within server 110) launches the voiceapplication as soon as the producer-specified date and time has arrived.In a preferred embodiment both on-demand and scheduled outboundapplication deployment functions support unicast, multicast andbroadcast delivery schemes.

As described above, a voice application created by application server110 consists of one or more dialogs. The contents of each dialog can bestatic or dynamic. Static content is content sourcing from the voiceapplication producer. The producer creates the contents when the voiceapplication is created. Dynamic content sources from a third-party datasource.

In a preferred embodiment a developers tool contains an interactivedialog design panel (described in detail later) wherein a producerinputs a reference link in the form of eXtensible Markup Language (XML)to the dialog description or response field. When a dialog response isexecuted and interpreted by application server 110, the reference linkinvokes a resource Application-Program-Interface (API) that isregistered in resource adapter 113. The API goes out in real time andretrieves the requested data and integrates the returned data into theexisting dialog. The resulting and subsequent VXML page being generatedhas the dynamic data embedded onto it.

One object of the present invention is a highly dynamic, real time IVRsystem that tailors itself automatically to the application developer'sspecified data source requirement. Another object of the presentinvention is to enable rapid development and deployment of a voiceapplication without requirement of any prior knowledge of VXML or anyother programming technologies. A further object of the presentinvention is to reduce the typical voice application production cycleand drastically reduce the cost of production.

FIG. 2 is a process flow diagram illustrating steps for creating a voiceapplication shell or container for a VXML voice application according toan embodiment of the present invention. A developer utilizing a clientapplication known as a thin client analogous to CL 141 on station 140described with reference to FIG. 1 b, creates a voice application shellor voice application container. At step 201 the developer logs in to thesystem at a login page. At step 202 the developer creates a contact listof application consumers. Typically a greeting or welcome page would bedisplayed before step 202. An application consumer is an audience of oneor more entities that would have access to and interact with a voiceapplication. A contact list is first created so that all of the intendedcontacts are available during voice application creation if call routinglogic is required later on. The contact list can either be enteredindividually in the event of more than one contact by the producer ormay be imported as a set list from some organizer/planner software, suchas Microsoft Outlook™ or perhaps a PDA™ organizer.

In one embodiment of the present invention the contact list may resideon an external device accessed by a provided connector (not shown) thatis configured properly and adapted for the purpose of accessing andretrieving the list. This approach may be used, for example, if a large,existing customer database is used. Rather than create a copy, theneeded data is extracted from the original and provided to theapplication.

At step 203, a voice application header is populated. A voiceapplication header is simply a title field for the application. Thefield contains a name for the application and a description of theapplication. At step 204, the developer assigns either and inbound oroutbound state for the voice application. An outbound application isdelivered through an outbound call while the consumer accesses aninbound voice application.

In the case of the inbound application, in step 205 the system sets adefault addressee for inbound communications. The developer selects adialog from a configured list in step 206. It is assumed in this examplethat the dialogs have already been created. At step 207, the developerexecutes the dialog and it is deployed automatically.

In the case of an outbound designation in step 204, the developerchooses a launch type in step 208. A launch type can be either anon-demand type or a scheduled type. If the choice made by the developerin step 208 is scheduled, then in step 209, the developer enters all ofthe appropriate time and date parameters for the launch includingparameters for recurring launches of the same application. In the caseof an on demand selection for application launch in step 208, then instep 210 the developer selects one or more contacts from the contactlist established in step 202. It is noted herein that step 210 is alsoundertaken by the developer after step 209 in the case of a scheduledlaunch. At step 207, the dialog is created. In this step a list ofprobable dialog responses for a voice application wherein interaction isintended may also be created and stored for use.

In general sequence, a developer creates a voice application andintegrates the application with a backend data source or, optionally,any third party resources and deploys the voice application. Theapplication consumer then consumes the voice application and optionally,the system analyzes any consumer feedback collected by the voiceapplication for further interaction if appropriate. The steps of thisexample pertain to generating and launching a voice application from“building blocks” that are already in place.

FIG. 3 is a block diagram illustrating a simple voice applicationcontainer 300 according to an embodiment of the present invention.Application container 300 is a logical container or “voice applicationobject” 300. Also termed a shell, container 300 is logically illustratedas a possible result of the process of FIG. 2 above. Container 300contains one or more dialog states illustrated herein as dialogs 301 a-nlabeled in this example as dialogs 1-4. Dialogs 301 a-n are objects andtherefore container 300 is a logical grouping of the set of dialogobjects 301 a-n.

The represented set of dialog objects 301 a-n is interlinked by businessrules labeled rules 1-4 in this example. Rules 1-4 are defined by thedeveloper and are rule objects. It is noted herein that that there maybe many more or fewer dialog objects 301 a-n as well as interlinkingbusiness rule objects 1-4 comprising container object 300 withoutdeparting from the spirit and scope of the present invention. Theinventor illustrates 4 of each entity and deems the representationsufficient for the purpose of explaining the present invention.

In addition to the represented objects, voice application shell 300includes a plurality of settings options. In this example, basicsettings options are tabled for reference and given the element number305 a-c illustrating 3 listed settings options. Reading in the tablefrom top to bottom, a first setting launch type (305 a) defines aninitial entry point for voice application 300 into the communicationssystem. As described above with reference to FIG. 2 step 204, thechoices for launch type 305 a are inbound or outbound. In an alternativeembodiment, a launch type may be defined by a third party and be definedin some other pattern than inbound or outbound.

Outbound launch designation binds a voice application to one or moreaddressees (consumers). The addressee may be a single contact or a groupof contacts represented by the contact list or distribution list alsodescribed with reference to FIG. 2 above (step 202). When the outboundvoice application is launched in this case, it is delivered to theaddressee designated on a voice application outbound contact field (notshown). All addressees designated receive a copy of the outbound voiceapplication and have equal opportunity to interact (if allowed) with thevoice application dialog and the corresponding backend data resources ifthey are used in the particular application.

In the case of an inbound voice application designation for launch type305 a, the system instructs the application to assume a ready stand-bymode. The application is launched when the designated voice applicationconsumer actively makes a request to access the voice application. Atypical call center IVR system assumes this type of inbound application.

Launch time setting (305 b) is only enabled as an option if the voiceapplication launch type setting 305 a is set to outbound. The launchtime setting is set to instruct a novel scheduling engine, which may beassumed to be part of the application server function described withreference to FIG. 1B. The scheduling engine controls the parameter ofwhen to deliver of when to deliver the voice application to thedesignated addressees. The time setting may reflect on-demand, scheduledlaunch, or any third-party-defined patterns.

On-demand gives the developer full control over the launch time of thevoice application. The on-demand feature also allows any third-partysystem to issue a trigger event to launch the voice application. It isnoted herein that in the case of third-party control the voiceapplication interaction may transcend more than one communicationssystem and or network.

Property setting 305 c defines essentially how the voice applicationshould behave in general. Possible state options for setting 305 c arepublic, persistent, or sharable. A public state setting indicates thatthe voice application should be accessible to anyone within the voiceportal domain so that all consumers with minimum privilege can accessthe application. A persistent state setting for property 305 c ensuresthat only one copy of the voice application is ever active regardless ofhow many consumers are attempting to access the application. An exampleof such a scenario would be that of a task-allocation voice application.For example, in a task-allocation scenario there are only a number oftime slots available for a user to access the application. If the taskis a request from a pool of contacts such as perhaps customer-supporttechnicians to lead a scheduled chat session, then whenever a time slothas been selected, the other technicians can only select the slots thatare remaining. Therefore if there is only one copy of the voiceapplication circulating within the pool of technicians, the applicationcaptures the technician's response on a first-come first-serve basis.

A sharable application state setting for property 305 a enables theconsumer to “see” the responses of other technicians in the dialog atissue, regardless of whether the voice application is persistent or not.Once the voice application shell is created, the producer can thencreate the first dialog of the voice application as described withreference to FIG. 2 step 207. It is reminded herein that shell 300 ismodeled using a remote and preferably a desktop client that will bedescribed in more detail later in this specification.

FIG. 4 is a block diagram illustrating a dialog object model 400according to an embodiment of the present invention. Dialog object model400 is analogous to any of dialog objects 301 a-n described withreference to FIG. 3 above. Object 400 models a dialog and all of itsproperties. A properties object illustrated within dialog object 400 andlabeled Object Properties (410) contains the dialog type and propertiesincluding behavior states and business rules that apply to the dialog.

For example, every dialog has a route-to property illustrated in theexample as Route To property (411). Property 411 maps to and identifiesthe source of the dialog. Similarly, every dialog has a route-fromproperty illustrated herein as Route From property (412). Route fromproperty 412 maps to and identifies the recipient contact of the dialogor the dialog consumer.

Every dialog falls under a dialog type illustrated in this example by aproperty labeled Dialog Type and given the element number 413. Dialogtype 413 may include but is not limited to the following types ofdialogs:

-   -   1. Radio Dialog: A radio dialog allows a voice application        consumer to interactively select one of available options from        an option list after hearing the dialog description.    -   2. Bulletin Dialog: A bulletin dialog allows a voice application        consumer to interact with a bulletin board-like forum where        multiple consumers can share voice messages in an asynchronous        manner.    -   3. Statement Dialog: A statement dialog plays out a statement to        a voice application consumer without expecting any responses        from the consumer.    -   4. Open Entry Dialog: An open entry dialog allows a voice        application consumer to record a message of a pre-defined length        after hearing the dialog description.    -   5. Third Party Dialog: A third party dialog is a modular        container structure that allows the developer to create a        custom-made dialog type with its own properties and behaviors.        An example would be Nuance's SpeechObject™.

Each dialog type has one or more associated business rules tagged to itenabling determination of a next step in response to a perceived state.A rule compares the application consumer response with an operanddefined by the application developer using an operational code such asless than, greater than, equal to, or not equal to. In a preferredembodiment of the invention the parameters surrounding a rule are asfollows:

If user response is equal to the predefined value, then perform one ofthe following:

A. Do nothing and terminate the dialog state.

B. Do a live bridge transfer to the contact specified. Or,

C. Send another dialog to another contact.

In the case of an outbound voice application, there are likely to beexception-handling business rules associated with perceived states. In apreferred embodiment of the present invention, exception handling rulesare encapsulated into three different events:

-   -   1. An application consumer designated to receive the voice        application rejects a request for interacting with the voice        application.    -   2. An application consumer has a busy connection at the time of        launch of the voice application, for example, a telephone busy        signal. And,    -   3. An application consumer's connection is answered by or is        redirected to a non-human device, for example, a telephone        answering machine.

For each of the events above, any one of the three follow-up actions arepossible according to perceived state:

1. Do nothing and terminate the dialog state.

2. Redial the number.

3. Send another dialog to another contact.

FIG. 5 is a process flow diagram illustrating steps for voice dialogcreation for a VXML-enabled voice application according to an embodimentof the present invention. All dialogs can be reused for subsequentdialog routing. There is, as previously described, a set of businessrules for every dialog and contact pair. A dialog be active and be ableto transit from one dialog state to another only when it is ruleenabled.

At step 501 a developer populates a dialog description field with adialog description. A dialog description may also contain reference toXML tags as will be described further below. At step 502, parameters ofthe dialog type are entered based on the assigned type of dialog.Examples of the available parameters were described with reference toFIG. 4 above.

At step 503 the developer configures the applicable business rules forthe dialog type covering, as well, follow up routines. In one embodimentrules configuration at step 503 resolves to step 505 for determiningfollow-up routines based on the applied rules. For example, thedeveloper may select at step 505, one of three types of transfers. Forexample, the developer may configure for a live transfer as illustratedby step 506; transfer to a next dialog for creation as illustrated bystep 507; or the developer may configure for dialog completion asillustrated by step 508.

If the developer does not branch off into configuring sub-routines 506,507, or 508 from step 505, but rather continues from step 503 to step504 wherein inbound or outbound designation for the dialog is systemassigned, then the process must branch from step 504 to either step 508or 509, depending on whether the dialog is inbound or outbound. If atstep 504, the dialog is inbound, then at step 508 the dialog iscompleted. If the assignment at step 504 is outbound, then at step 509to configure call exception business rules.

At step 510, the developer configures at least one follow-up action forsystem handling of exceptions. If no follow-up actions are required tobe specified at step 510, then the process resolves to step 508 fordialog completion. If an action or actions are configured at step 510,then at step 511 the action or actions are executed such as a systemre-dial, which the illustrated action for step 511.

In a preferred embodiment, once the voice application has been created,it can be deployed and accessed through the telephone. The method ofaccess, of course, depends on the assignment configured at step 504. Forexample, if the application is inbound, the application consumeraccesses a voice portal to access the application. As described furtherabove, a voice portal is a voice interface for accessing a selectednumber of functions of the voice application server described withreference to FIG. 1B above. A voice portal may be aconnection-oriented-switched-telephony (COST) enabled portal or adata-network-telephony (DNT) enabled portal. In the case of an outbounddesignation at step 504, the application consumer receives the voiceapplication through an incoming call to the consumer originated from thevoice application server. In a preferred embodiment, the outbound callcan be either COST based or DNT based depending on the communicationsenvironment supported.

FIG. 6 is a block diagram illustrating a dialog transition flow afterinitial connection with a consumer according to an embodiment of thepresent invention. Some of the elements illustrated in this example werepreviously introduced with respect to the example of FIG. 1B above andtherefore shall retain their original element numbers. In this example,an application consumer is logically illustrated as Application Consumer600 that is actively engaged in interaction with a dialog 601 hosted bytelephony server 130. Server 130 is, as previously described a VMXLcompliant telephony server as is so labeled.

Application server 110 is also actively engaged in the interactionsequence and has the capability to provide dynamic content to consumer600. As application consumer 600 begins to interact with the voiceapplication represented herein by dialog 600 within telephony server130, voice application server 110 monitors the situation. In actualpractice, each dialog processed and sent to server 130 for delivery toor access by consumer 600 is an atomic unit of the particular voiceapplication being deployed and executed. Therefore dialog 601 maylogically represent more than one single dialog.

In this example, assuming more than one dialog, dialog 601 isresponsible during interaction for acquiring a response from consumer600. Arrows labeled Send and Respond represent the describedinteraction. When consumer 600 responds to dialog content, the responseis sent back along the same original path to VXML rendering engine 111,which interprets the response and forwards the interpreted version to aprovided dialog controller 604. Controller 604 is part of applicationlogic 112 in server 110 described with reference to FIG. 1B. Dialogcontroller 604 is a module that has the ability to perform tablelookups, data retrieve and data write functions based on establishedrules and configured response parameters.

When dialog controller 604 receives a dialog response, it stores theresponse corresponding to the dialog at issue (601) to a provided datasource 602 for data mining operations and workflow monitoring.Controller 604 then issues a request to a provided rules engine 603 tolook-up the business rule or rules that correspond to the storedresponse. Once the correct business rule has been located for theresponse, the dialog controller starts interpretation. If the businessrule accessed requires reference to a third-party data source (notshown), controller 604 makes the necessary data fetch from the source.Any data returned by controller 604 is integrated into the dialogcontext and passed onward VXML rendering engine 111 for dialog pagegeneration of a next dialog 601. The process repeats until dialog 601 isterminates.

In one embodiment, the business rule accessed by controller 604 as aresult of a received response from consumer 600 carries a dialogtransition state other than back to the current application consumer. Inthis case controller 604 spawns an outbound call from application server110 to deliver the next or “generated dialog” to the designated targetapplication consumer. At the same time, the current consumer has his/herdialog state completed as described with reference to FIG. 5 step 508according to predefined logic specified in the business rule.

It will be apparent to one with skill in the art that a dialog cancontain dynamic content by enabling controller 604 to have access todata source 602 according to rules served by rule engine 603. In mostembodiments there are generally two types of dynamic content. Both typesare, in preferred embodiments, structured in the form of XML and areembedded directly into the next generated dialog page. The first of the2 types of dynamic content is classified as non-recurring. Non-recurringcontent makes a relative reference to a non-recurring resource label ina resource adapter registry within a resource adapter analogous toadapter 113 of voice application server 110 described with reference toFIG. 1B.

In the above case, when dialog controller 604 interprets the dialog, itfirst scans for any resource label. If a match is found, it looks up theresource adapter registry and invokes the corresponding resource API tofetch the required data into the new dialog context. Once the raw datais returned from the third-party data source, it passes the raw data toa corresponding resource filter for further processing. When completedin terms of processing by the filter, the dialog resource label or tagis replaced with the filtered data and is integrated transparently intothe new dialog.

The second type of dynamic content is recurring. Recurring contentusually returns more than one set of a name and value pair. An examplewould be a list of stocks in an application consumer's stock portfolio.For example, a dialog that enables consumer 600 to parrot a specificstock and have the subsequent quote returned through another dialogstate is made to use recurring dynamic content to achieve the desiredresult. Recurring content makes a relative reference to a recurringresource label in the resource adapter registry of voice applicationserver 110. When controller 604 interprets the dialog, it handles theresource in an identical manner to handling of non-recurring content.However, instead of simply returning the filtered data back to thedialog context, it loops through the data list and configures eachlisted item as a grammar-enabled keyword. In so doing, consumer 600 canparrot one of the items (separate stocks) in the list played in thefirst dialog and have the response captured and processed for return inthe next dialog state. The stock-quote example presented belowillustrates possible dialog/response interactions from the viewpoint ofconsumer 600.

Voice Application: “Good morning Leo, what stock quote do you want?”

Application Consumer: “Oracle”

Voice Application: “Oracle is at seventeen dollars.”

Voice Application: “Good morning Leo, what stock quote do you want?”

This particular example consists of two dialogs.

The first dialog plays out the statement “Good morning Leo, what stockquote do you want?” The dialog is followed by a waiting state thatlistens for keywords such as Oracle, Sun, Microsoft, etc. The statementconsists of two dynamic non-recurring resource labels. The first one isthe time in day: Good morning, good afternoon, or good evening. Thesecond dynamic content is the name of the application consumer. In thiscase, the name of the consumer is internal to the voice applicationserver, thus the type of the resource label is SYSTEM. In the actualdialog description field, it may look something like this:

-   -   <resource type=‘ADAPTER’ name=‘time greeting’/> <resource        type=‘SYSTEM’ name=‘target_contact’/>, what stock quote do you        want?

Because the dialog is expecting the consumer to say a stock out ofhis/her existing portfolio, the dialog type is radio dialog, and theexpected response property of the radio dialog is

<resource type=’ADAPTER’ name=’stock_list’> <param> <resourcetype=’SYSTEM’ name=’target_contact_id’/> </param> </resource>

This XML resource label tells dialog controller 604 to look for aresource label named stock_list and to invoke the corresponding API withtarget_contact_id as the parameter. Upon completion of the datafetching, the list of stocks is integrated into the dialog as part ofthe grammars. And whatever the user responds to in terms of stockidentification is matched against the grammars at issue (stocks inportfolio) and assigned the grammar return value to the dialog response,which can then forward it to the next dialog as resource of DIALOG type.

The producer can make reference to any dialog return values in anysubsequent dialog by using <resource type=‘DIALOG’ name=‘dialog_name’/>.This rule enables the producer to play out the options the applicationconsumer selected previously in any follow-up dialogs.

The second dialog illustrated above plays out the quote of the stockselected from the first dialog, then returns the flow back to the firstdialog. Because no extra branching logic is involved in this dialog, thedialog type in this case is a statement dialog. The dialog's follow-upaction is simply to forward the flow back to the first dialog. In such acase, the dialog statement is:

<resource type=’DIALOG’ name=’select stock dialog’/> <resourcetype=’ADAPTER’ name=’get_stock_quote’> <param> <resource type=’DIALOG’name=’select stock dialog’/> </param> </resource>

Besides making reference to ADAPTER, DIALOG and SYSTEM type, the dialogcan also take in other resource types such as SOUND and SCRIPT. SOUNDcan be used to impersonate the dialog description by inserting a soundclip into the dialog description. For example, to play a sound after thestock quote, the producer inserts <resource type=‘SOUND’ name=‘beep’/>right after the ADAPTER resource tag.

The producer can add a custom-made VXML script into the dialogdescription by using <resource type=‘RESOURCE’ name=‘confirm’/> so thatin the preferred embodiment, any VXML can be integrated into the dialogcontext transparently with maximum flexibility and expandability.

It will be apparent to one with skill in the art that while the examplecited herein use VXML and XML as the mark-up languages and tags, it isnoted herein that other suitable markup languages can be utilized inplace of or integrated with the mentioned conventions without departingfrom the spirit and scope of the invention. It will also be apparent tothe skilled artisan that while the initial description of the inventionis made in terms of a voice application server having interface to atelephony server using generally HTTP requests and responses, it shouldbe noted that the present invention can be practiced in any system thatis capable of handling well-defined requests and responses across anydistributed network.

FIGS. 7-15 illustrate various displayed Browser frames of a developerplatform interface analogous to CL 141 of station 140 of FIG. 1B.Description of the following interface frames and frame contents assumesexistence of a desktop computer host analogous to station 140 of FIG. 1Bwherein interaction is enabled in HTTP request/response format as wouldbe the case of developing over the Internet network for example.However, the following description should not limit the method andapparatus of the invention in any way as differing protocols, networks,interface designs and scope of operation can vary.

FIG. 7 is a plan view of a developer's frame containing a developer'slogin screen of 700 according to an embodiment of the present invention.Frame 700 is presented to a developer in the form of a Web browsercontainer according to one embodiment of the invention. Commercial Webbrowsers are well known and any suitable Web browser will support theplatform. Frame 700 has all of the traditional Web options associatedwith most Web browser frames including back, forward, Go, File, Edit,View, and so on. A navigation tool bar is visible in this example.Screen 710 is a login page. The developer may, in one embodiment, have adeveloper's account. In another case, more than one developer may sharea single account. There are many possibilities.

Screen 710 has a field for inserting a login ID and a field forinserting a login personal identification number (PIN). Once loginparameters are entered the developer submits the data by clicking on abutton labeled Login. Screen 710 may be adapted for display on a desktopcomputer or any one of a number of other network capable devicesfollowing specified formats for display used on those particulardevices.

FIG. 8 is a plan view of a developer's frame 800 containing a screenshot of a home page of the developer's platform interface of FIG. 7.Frame 800 contains a sectioned screen comprising a welcome section 801,a product identification section 802 and a navigation section 803combined to fill the total screen or display area. A commercial name fora voice application developer's platform that is coined by the inventoris the name Fonelet. Navigation section 803 is provided to display onthe “home page” and on subsequent frames of the software tool.

Navigation section 803 contains, reading from top to bottom, a pluralityof useful links. Starting with a link to home followed by a link to anaddress book. A link for creating a new Fonelet (voice application) islabeled Create New. A link to “My” Fonelets is provided as well as alink to “Options”. A standard Help link is illustrated along with a linkto Logout. An additional “Options Menu” is the last illustrated link insection 803. Section 803 may have additional links that are visible byscrolling down with the provided scroll bar traditional to the type ofdisplay of this example.

FIG. 9 is a plan view of a developer's frame 900 containing a screenshot of an address book 911 accessible through interaction with theoption Address in section 803 of the previous frame of FIG. 8. Screen911 as an interactive option for listing individual contacts and forlisting contact lists. A contact list is a list of voice applicationconsumers and a single contact represents one consumer in this example.However, in other embodiments a single contact may mean more than oneentity. Navigation screen 803 is displayed on the left of screen 911. Inthis example, contacts are listed by First Name followed by Last Name,followed by a telephone number and an e-mail address. Other contactparameters may also be included or excluded without departing from thespirit and scope of the invention. For example the Web site of a contactmay be listed and may also be the interface for receiving a voiceapplication. To the left of the listed contacts are interactiveselection boxes used for selection and configuration purposes.Interactive options are displayed in the form of Web buttons and adaptedto enable a developer to add or delete contacts.

FIG. 10 is a plan view of a developer's frame 1000 displaying a screen1001 for creating a new voice application. Screen 1001 initiatescreation of a new voice application termed a Fonelet by the inventor. Aname field 1002 is provided in screen 1001 for inputting a name for theapplication. A description field 1003 is provided for the purpose ofentering the applications description. A property section 1004 isillustrated and adapted to enable a developer to select from availableoptions listed as Public, Persistent, and Shareable by clicking on theappropriate check boxes.

A Dialog Flow Setup section is provided and contains a dialog typesection field 1005 and a subsequent field for selecting a contact orcontact group 1006. After the required information is correctlypopulated into the appropriate fields, a developer may “create” thedialog by clicking on an interactive option 1007 labeled Create.

FIG. 11 is a plan view of a developer's frame 1100 illustrating screen1001 of FIG. 10 showing further options as a result of scrolling down. Acalling schedule configuration section 1101 is illustrated and providesthe interactive options of On Demand or Scheduled. As was previouslydescribed, selecting On Demand enables application deployment at thewill of the developer while selecting scheduled initiates configurationfor a scheduled deployment according to time/date parameters. A groupingof entry fields 1102 is provided for configuring Time Zone and Month oflaunch. A subsequent grouping of entry fields 1103 is provided forconfiguring the Day of Week and the Day of Month for the scheduledlaunch. A subsequent grouping of entry fields 1104 is provided forconfiguring the hour and minute of the scheduled launch. It is notedherein that the options enable a repetitive launch of the sameapplication. Once the developer finishes specifying the voiceapplication shell, he or she can click a Create Dialog button labeledCreate to spawn an overlying browser window for dialog creation.

FIG. 12 is a screen shot of a dialog configuration window 1200illustrating a dialog configuration page according to an embodiment ofthe invention. In this window a developer configures the first dialogthat the voice application or Fonelet will link to. A dialogidentification section 1201 is provided for the purpose of identifyingand describing the dialog to be created. A text entry field for enteringa dialog name and a text entry field for entering dialog description areprovided. Within the dialog description field, an XML resource tag (notshown) is inserted which for example, may refer to a resource labelmachine code registered with a resource adapter within the applicationserver analogous to adapter 113 and application server 110 describedwith reference to FIG. 1B.

A section 1202 is provided within screen 1200 and adapted to enable adeveloper to configure for expected responses. In this case the type ofdialog is a Radio Dialog. Section 1202 serves as the business rule logiccontrol for multiple choice-like dialogs. Section 1202 contains aselection option for Response of Yes or No. It is noted herein thatthere may be more and different expected responses in addition to asimple yes or no response.

An adjacent section is provided within section 1202 for configuring anyFollow-Up Action to occur as the result of an actual response to thedialog. For example, an option of selecting No Action is provided foreach expected response of Yes and No. In the case of a follow-up action,an option for Connect is provided for each expected response. Adjacentto each illustrated Connect option, a Select field is provided forselecting a follow-up action, which may include fetching data.

A Send option is provided for enabling Send of the selected follow-upaction including any embedded data. A follow-up action may be any typeof configured response such as send a new radio dialog, send a machinerepair request, and so on. A send to option and an associated selectoption is provided for identifying a recipient of a follow-up action andenabling automated send of the action to the recipient. For example, ifa first dialog is a request for machine repair service sent to aplurality of internal repair technicians, then a follow-up might be tosend the same dialog to the next available contact in the event thefirst contact refused to accept the job or was not available at the timeof deployment.

In the above case, the dialog may propagate from contact to contact downa list until one of the contacts is available and chooses to interactwith the dialog by accepting the job. A follow-up in this case may be tosend a new dialog to the accepting contact detailing the parameters ofwhich machine to repair including the diagnostic data of the problem andwhen the repair should take place. In this example, an option forshowing details is provide for developer review purposes. Alsointeractive options for creating new or additional responses and fordeleting existing responses from the system are provided. It is notedherein that once a dialog and dialog responses are created then they arereusable over the whole of the voice application and in any specifiedsequence in a voice application.

A section 1203 is provided within screen 1201 and adapted for handlingRoute-To Connection Exceptions. This section enables a developer toconfigure what to de in case of possible connection states experience inapplication deployment. For example, for a Caller Reject, Line Busy, orconnection to Voice Mail there are options for No Action and for Redialillustrated. It is noted herein that there may be more Exceptions aswell as Follow-up action types than are illustrated in this examplewithout departing from the spirit and scope of the present invention.

A Send option is provided for each type of exception for re-sending thesame or any other dialog that may be selected from an adjacent drop downmenu. For example if the first dialog is a request for repair servicesand all of the initial contacts are busy for example, the dialog may besent back around to all of the contacts until one becomes available byfirst moving to a next contact for send after each busy signal and thenbeginning at the top of the list again on re-dial. In this case John Doerepresents a next recipient after a precious contact rejects the dialog,is bust, or re-directs to voice mail because of unavailability. Section1203 is only enabled when the voice application is set to outbound. Oncethe first dialog is created and enabled by the developer then a seconddialog may be created if desired by clicking on one of the availablebuttons labeled detail. Also provided are interactive buttons for SaveDialog, Save and Close, and Undo Changes.

FIG. 13 is a screen shot 1300 of dialog design panel 1200 of FIG. 12illustrating progression of dialog state to a subsequent contact. Thedialog state configured in the example of FIG. 12 is now transmittedfrom a contact listed in Route From to a contact listed in Route To insection 1301, which is analogous to section 1201 of FIG. 12. In thiscase, the contacts involved are John Doe and Jane Doe. In this case, thedialog name and description are the same because the dialog is beingre-used. The developer does not have to re-enter any of the dialogcontext. However, because each dialog has a unique relationship with arecipient the developer must configure the corresponding business rules.

Sections 1302 and 1303 of this example are analogous to sections 1202and 1203 of the previous example of FIG. 12. In this case if John Doesays no to the request for machine repair then the system carries out abridge transfer to Jane Doe. In the case of exceptions, shown inRoute-To Connection Exceptions region 1303, all the events are directedto a redialing routine. In addition to inserting keywords such as “Yes”or “No” in the response field 1302, the developer can create a customthesaurus by clicking on a provided thesaurus icon not shown in thisexample. All the created vocabulary in a thesaurus can later be re-usedthroughout any voice applications the developer creates.

FIG. 14 is a screen shot of a thesaurus configuration window 1400activated from the example of FIG. 13 according to a preferredembodiment. Thesaurus window 1400 has a section 1401 containing a fieldfor labeling a vocabulary word and an associated field for listingsynonyms for the labeled word. In this example, the word no isassociated with probable responses no, nope, and the phrase “I can notmake it”. In this way voice recognition regimens can be trained in apersonalized fashion to accommodate for varieties in a response thatmight carry a same meaning.

A vocabulary section 1402 is provided and adapted to list all of thecreated vocabulary words for a voice application and a selectionmechanism (a selection bar in this case) for selecting one of the listedwords. An option for creating a new word and synonym pair is alsoprovided within section 1402. A control panel section 1403 is providedwithin window 1400 and adapted with the controls Select From Thesaurus;Update Thesaurus; Delete From Thesaurus; and Exit Thesaurus.

FIG. 15 is a plan view of a developer's frame 1500 illustrating a screen1502 for managing created modules according to an embodiment of thepresent invention.

After closing all dialog windows frame 1500 displays screen or page 1502for module management options. Menu section 803 is again visible. Screen1502 displays as a result of clicking on the option “My” or My Foneletin frame 803. Screen 1502 lists all voice applications that are alreadycreated and usable. In the list, each voice application has a check boxadjacent thereto, which can be selected to change state of theparticular application. A column labeled Status is provided withinscreen 1502 and located adjacent to the application list applicationsalready created.

The Status column lists the changeable state of each voice application.Available status options include but are not limited to listed states ofInactive, Activated and Inbound. A column labeled Direct Access ID isprovided adjacent to the Status column and is adapted to enable thedeveloper to access a voice application directly through a voiceinterface in a PSTN network or in one embodiment from a DNT voiceinterface. In a PSTN embodiment, direct access ID capability serves asan extension of a central phone number. A next column labeled Action isprovided adjacent to the direct access ID column and is adapted toenable a developer to select and apply a specific action regarding stateof a voice application.

For example, assume that a developer has just finished the voiceapplication identified as Field Support Center (FSC) listed at the topof the application identification list. Currently, the listed state ofFSC is Inactive. The developer now activates the associated Action dropdown menu and selects Activate to launch the application FSC on demand.In the case of a scheduled launch, the voice application is activatedautomatically according to the settings defined in the voice applicationshell.

As soon as the Activate command has been issued, the on-demand requestis queued for dispatching through the system's outbound applicationserver. For example, John Doe then receives a call originating from thevoice application server (110) that asks if John wants to take the call.If John responds “Yes,” the voice application is executed. The actualcall flow follows:

System: “Hello John, you received a fonelet from Jim Doe, would you liketo take this call?”

John: “Yes.”

System: “Machine number 008 is broken, are you available to fix it?”

John: “No.”

System: “Thanks for using fonelet. Goodbye!”

System: Terminate the connection with John, record the call flow to thedata source, and spawn a new call to Jane Doe.

System: “Hello Jane, you received a fonelet from Jim Doe, would you liketo take this call?”

Jane: “Yes.”

System: “Machine number 008 is broken, are you available to fix it?”

Jane: “I cannot make it.”

System: “Please wait while fonelet transfers you to Jeff Doe.”

System: Carry out the bridge transfer between Jane Doe and Jeff Doe.

When the conversation is completed, terminate the connection with Jeffand record the call flow to the data source.

The default textual content of the voice application is being generatedby the text-to-speech engine hosted on the telephony or DNT server.However, the voice application producer can access the voice portalthrough the PSTN or DNT server and record his/her voice over anyexisting prompts in the voice application.

It will be apparent to one with skill in the art the method andapparatus of the present invention may be practiced in conjunction witha CTI-enabled telephony environment wherein developer access to forapplication development is enabled through a client application runningon a computerized station connected to a data network also havingconnectivity to the server spawning the application and telephonycomponents. The method and apparatus of the invention may also bepracticed in a system that is DNT-based wherein the telephony server andapplication server are both connected to a data network such as thewell-known Internet network. There are applications for all mixes ofcommunications environments including any suitable multi-tier systemenabled for VXML and or other applicable mark-up languages that mayserve similar purpose.

It will also be apparent to one with skill in the art that modelingvoice applications including individual dialogs and responses enablesany developer to create a limitless variety of voice application quicklyby reusing existing objects in modular fashion thereby enabling a widerange of useful applications from an existing store of objects.

Auto-Harvesting Web Data

In one embodiment of the present invention one or more Websites can beautomatically harvested for data to be rendered by a VXML engine forgenerating a voice response accessible by users operating through aPSTN-based portal. Such an enhancement is described immediately below.

FIG. 16 is a block diagram illustrating the dialog transition flow ofFIG. 6 enhanced for Web harvesting according to an embodiment of thepresent invention. Dialog controller 604 is enhanced in this embodimentto access and harvest data from an HTML, WML, or other data source suchas would be the case of data hosted on a Website. An example scenariofor this embodiment is that of a banking institution allowing all of itscustomers to access their Web site through a voice portal.

A Website 1600 is illustrated in this embodiment and is accessible todialog controller 604 via a network access line 1601 illustrated hereinas two directional lines of communication. The first line is labeledStore/Fetch/Input leading from controller 604 into site 1600. The second(return) line is labeled Data Return/Source Field. The separatelyillustrated communication lines are intended to be analogous to abi-directional Internet or other network access line. An internal datasource (602) previously described with reference to FIG. 6 above isreplaced in FIG. 16 by Website 1600 for explanatory purpose only. Itshould be noted that multiple data sources both internal to server 110and external from server 110 could be simultaneously accessible todialog controller 604.

Website 1600 provides at least one electronic information page (Webpage) that is formatted according to the existing rules for the mark-uplanguage that is used for its creation and maintenance. Site 1600 may beone site hosting many information pages, some of which are inter-relatedand accessible through subsequent navigation actions. Controller 604 inthis embodiment is enhanced for Website navigation at the direction of auser's voice inputs enabled by rule accessible by accessing rule engine603. A data template (not shown) is provided for use by dialogcontroller 604 to facilitate logical data population from site 1600.Dialog controller 604 analyzes both Website source codes and data fieldsas return data and uses the information to generate a VXML page forrendering engine 111.

It is noted herein that all of the security and access mechanisms usedat the site for normal Internet access are inferred upon the customer sothat the customer may be granted access by providing a voice rendering(response) containing the security access information. This enables thecustomer to keep the same security password and/or personalidentification number (PIN) for voice transactions through a portal aswell as for normal Web access to site 1600 from a network-connectedcomputer.

FIG. 17 is a block diagram of the voice application distributionenvironment of FIG. 1B illustrating added components for automated Webharvesting and data rendering according to an embodiment of the presentinvention. In this example, workstation 140 running client software 141has direct access to a network server 1701 hosting the target Website1600. Access is provided by way of an Internet access line 1704.

It is noted herein that there may be many servers 1701 as well as manyhosted Websites of one or more pages in this embodiment withoutdeparting from the spirit and scope of the present invention. A databasestore 1702 is provided in this example and illustrated as connected toserver 1701 for the purpose of storing data. Data store 1702 may be anoptical storage, magnetic storage, a hard disk, or other forms suitablefor storing data accessible online. In one embodiment, data store 1702is a relational database management system (RDBMS) wherein a singleaccess may involve one or more connected sub servers also storing datafor access.

The configuration of client application 141, workstation 140, server1702, Website 1600, and database 1702 connected by network 1704 enablesWebsites analogous to site 1600 to be culled or harvested. Application141 can read and retrieve all of the default responses that exist foreach HTML script or scripts of another mark-up language. These defaultresponses are embedded into application logic 112 and VXML renderingengine 111. Once the content of a Web page has been culled and used inclient 141 to create the rendering, then VXML engine 111 can access theWebsite successfully in combination with application logic 112 anddatabase/resource adaptor 113 by way of a separate access network 1703.For example, if a user (not shown) accesses Website 1600 through voiceportal 143 from receiving device 135 (telephone), then he or she wouldbe voice prompted for a password to gain access to the site.Subsequently, a voice rendering of the data on the site accessed wouldbe recited to him or her over telephone 135.

Generally speaking, the development process for a voice portal would bethe same as was described above with references to FIGS. 9-15 above.Some additional scripting or input of dialog is performed using clientapplication 141. Rather that requiring that the application developerpopulate all of the fields from scratch, or re-apply previously enteredoptions, fields used by the business logic as discussed earlier in FIGS.9 through 15 may be created from information harvested from site 1600 inthis case. For that purpose, a software adapter (not shown) is added toclient software 141 that allows it to communicate with Web site 1600 andharvest the information, both from the source code comprising fields andlabels, etc. as well as from data parameters and data variables. It isnoted herein that the process for data access, retrieval and voicerendering is essentially the same with respect to the processes of FIGS.2-5 above except that a Website connection would be established beforeany other options are selected.

In one embodiment, provision of connection 1703 between server 110 andserver 1701 enables the security environment practiced betweencommunicating machines such a secure socket layer (SSL), firewall, etcto be applied in the created voice solution for a customer. On theanalog side, the security is no different than that of a call-in lineallowing banking services in terms of wiretap possibilities etc.

It will be apparent to one with skill in the art that the method andapparatus of the invention can be practiced in conjunction with theInternet, an Ethernet, or any other suitable networks. Markup languagessupported include HTML, SHTML, WML, VHTML, XML, VXML and so on. In oneembodiment, the Websites accessed may be accessed automatically whereinthe password information for a user is kept at the site itself. Thereare many possible scenarios.

The method and apparatus of the invention should be afforded to broadestinterpretation under examination in view of the many possibleembodiments and uses. The spirit and scope of the invention is limitedonly be the claims that follow.

1. A system for developing and deploying a voice application usingWeb-based data as source data over a communications network to one ormore recipients, comprising: a voice application server connected to adata network for storing and serving voice applications, the voiceapplication server capable of accessing a network server and Websitehosted therein; a network communications server connected to the datanetwork and to the communications network for routing the voiceapplications to their intended recipients; a computer station connectedto the data network having control access to at least the voiceapplication server, the computer station capable of accessing thenetwork server and Website hosted therein; and a software applicationrunning on the computer station for creating applications and managingtheir states; characterized in that a developer operating the softwareapplication from the computer station accesses the target server andWebsite and creates at least one template for holding Web data accordingto logical order of site construction and links the templates to voiceapplications created by object modeling and linking, whereupon accordingto a triggering event, the triggered voice application accesses theintended Website and retrieves refreshed data from the site into thetemplate and renders the retrieved data as voice delivered to intendedrecipients.